IBIS Macromodel Task Group Meeting date: 08 September 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC * David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Todd had taken the minutes the previous week (09/01/2015). Todd had sent the minutes to Arpad for review, but the final version had not been completed and posted. Mike L. took the AR to complete the minutes and post them. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad to email the Editorial Committee with the ATM group's suggested rewording of the [C Comp Corner] sentences. - Done. [Arpad reviewed the final status in the New Discussion: section below] ------------------------- Review of Meeting Minutes: - Minutes for 01 September had not yet been posted. ------------- New Discussion: [C Comp Corner] update: - Arpad: We discussed the ATM group's recommendation in last Friday's Editorial meeting. - We came up with a sentence that was mailed to the IBIS reflector so that everyone would be informed prior to this Friday's Open Forum meeting. - The final proposed language is: [from Michael Mirmak's email] "If [C Comp Corner] is present, its subparameters take precedence over any and all C_comp, C_comp_* subparameters of [Model]." - The vote to approve IBIS 6.1 will be a conditional vote that includes making this change. - Hopefully everyone is okay with this language, since it came from the Editorial review of what ATM had proposed. - Any questions? [none] Item #6: Info, Out, InOut BIRD draft. - Arpad: In our last discussion of this topic two weeks ago, we seemed to agree: - We would use the existing syntax. - We would not introduce a new branch, parameter Type, etc. - We would just be clearer in the spec that some information should be in the model to let the user know if a non-standard parameter is used. - We did have some discussion on introducing a new Reserved parameter. - It could be called "proprietary" (values 0 or 1). - It could be called "interoperability" and list supporting EDA vendors. - Etc. - Walter: I understand the concept [of the new Reserved parameter]. - I dislike the name "proprietary" as it implies that you're not documenting what to do with the parameter. - Arpad: Before we get into the specifics, do we want to decide if we want to add a new Reserved parameter? - Ambrish: I think adding a new keyword is not a good idea. - Why add another layer of complexity if it's not enforceable? - Bob: Introduction of a Model Specific parameter that is not universally accepted or understood is still legal. It will still pass the parser. - What is being proposed is a Reserved parameter indicating that this AMI file includes parameters with special meanings or handling. - That might be acceptable as a Reserved parameter just for information. - Todd: Is the issue here that the model contains a parameter that affects simulation results in a non-standard way? - Bob: Yes. - Arpad: [responding to Ambrish's question] - I don't see any way to make this enforceable. - Model Specific is already not enforceable. - Can you see any way to make it enforceable? - Ambrish: With sufficient pressure from the customer of your model, you could resort to just removing the offending parameter and saying the model no longer has the issue. - The description in the model may have that information anyway, and that should be enough for the user. - John: Description strings are arbitrary and harder to parse. - Ambrish: The info is mostly for the user to be aware, not the tool. - Arpad: Last time we discussed a parameter that lists all the vendor specific Model Specific parameters. - Instead, we could add a new "vendor specific" leaf to all Model Specific parameters (value 0 or 1). - John: Either of those would make it easier for the tool to find that out. - Ambrish: Do we see many models that will need this kind of thing or not? - Are we adding this burden when most models won't need it? - Todd: When we started this discussion a few weeks ago: - I was tired of getting yelled at for putting new things in models. - You were tired of getting customer complaints if your simulator didn't support them. - Now, we are deliberately offering to highlight such parameters for the user to help us both out. - Model maker would have to defend the reasons for putting the parameter there. - I thought you said this was a source of pain. - Ambrish: Would this resolve it? - Walter: I would dismiss the suggestion for a new leaf for every Model Specific parameter. - The new parameter with a list of the special parameters is better. - Model maker should then be obligated to give an explanation for the parameters listed in this new Reserved parameter. - That would not affect any existing flows. - Arpad: [responding to Ambrish's frequency of occurrence question] - These types of models appear whenever there's a new feature appearing that the spec doesn't cover. - For example, if someone came up with a PAM9 and the spec only covers PAM4, then they would have to add Model Specific parameters for PAM9. - Suddenly, all these new PAM9 models would be proprietary. - Walter: I think your premise is wrong. - If there were a PAM9, the Model Maker would not just invent new parameters. - They would talk to their EDA vendor(s). [the folks on this committee] - Then we'd all agree on the needed parameters and converge on a PAM9 BIRD. - We'd agree, and as with PAM4 they would use the new Reserved parameters. - Arpad: Yes, but what happens while all that is shaking out? - While the BIRD is being discussed, those models are proprietary solutions. - Ambrish: Ideally that would not take place, and those proprietary models would not slip out to customers. - Todd: That's not realistic. They don't "slip out". - They are shipped intentionally in order to get a job done. - Ambrish: Is this a problem that could be fixed? - I don't think it could. - Walter: As a practical matter I think there are two things appearing in models that are not compliant with the standard. - 1. tstone files - 2. dependency tables. - Tstone files can already be addressed in 6.0 by using External Models if the model maker and EDA vendor want to support it. - Dependency tables will be addressed in 6.1. Once 6.1 is released, model makers should be adding an AMI_Resolve() function to their .dlls. - Radek: That's a suggested way of handling those particular upgrades. - What about the models that have been used in the past? - A user may not be up to date on the latest standard. They just get an old AMI model and try to use it. - It is really fair to inform the user if special parameters are used. - Those old models are not going to disappear. We have no control over that. - It is fair to put that information in for the user, whether it's 5, 10 or 30 percent of models that might be affected. - Walter: I agree. - Suppose in 6.2 we add Reserved parameter XYZ that lists all of the special parameters. Someone can then take a 5.1 file, convert it to 6.2, add the new XYZ that lists the parameters, and this issue is solved. - Todd: Do we have a problem worth solving? - Arpad: I think we do. - Todd: I now hear Ambrish saying we don't? - John: Walter went to a slightly different example, taking an older model and updating the version and adding the new keyword. - That's an area that is a big problem. - A lot of older models have not been updated to the latest AMI version. - A bit earlier we were talking about the interval of time between a new prototype being released to users and the actual parameters getting approved and tools getting updated to use them. - Ambrish: Don't you think model makers would just update their old models according to Walter's example? - They could just add the new keyword and not actually bring the model up to the latest spec by doing it the new approved way. - Todd: You're right. - Some model makers will not invest the cost to go rewrite an ASCII dependency table using AMI_Resolve(). - But at least it's out in the open and the user knows about it. - Radek: And we don't have to have it enforceable. - We care about the user so we want to put this information in the AMI file. - What's to enforce? - Arpad: If someone writes a model that is vendor specific today, and later on the spec adds that capability, is there a way to make that model work in all tools (interoperably) without changing anything since the new spec supports the previously proprietary feature of the model? - Assume for this discussion that the spec implements the feature exactly as it was initially prototyped in the vendor specific model (same name, etc.). - Ambrish: There are too many ifs. - Walter: It's simple, take the Modulation parameter introduced for PAM4. - It was Model Specific in 6.0. - Anyone can take that AMI file, change it to 6.1, move that parameter into Reserved and get rid of the XYZ parameter. - Radek: Yes, then it's ready to go. - But there's no way to even know if you could just map an old Model Specific parameter to a new Reserved parameter. Only the model maker would know for sure if the implementation were identical and the model didn't need to be updated. - So only the model maker would know if you could just update the AMI file. - Ambrish: That's half the people. What about those who never get their changes approved and in the spec? - Walter: There are lessons to be learned when we look at BIRDs in the future. - PAM4 BIRD - I think we did that extremely well. We iterated through the process quickly. I think everyone involved will find it easy to upgrade to IBIS 6.1. - Tstone file and Ext Model - I think we did okay. At least we gave a path for vendors to migrate to Ext Model. - I think we did the wrong thing with Dependency Tables. Instead of making incremental changes, this group made the decision that they weren't flexible enough. We chose a path that it was clear would make it very difficult for people to upgrade [to AMI_Resolve()]. The problem was that we didn't come up with that decision in a timely fashion. It's now coming in 6.1, but it has been 4 or 5 years since dependency tables were introduced. - The lesson is that we should make it easy to upgrade the model to the approved way, or at least introduce the new method more quickly. - Todd: There's one other hypothesis. - One of the value statements for going to binary dependency tables [i.e. AMI_Resolve()] was that people would want to hide the dependency mechanism and not have it documented in plain text. - That was a justification given, and it's legitimate. - However, maybe it's not true in practice. Maybe people don't care about that enough to want to go implement AMI_Resolve(). - Right now we see there's not enough demand in the market to drive people to write and adopt models with Dependency Tables. Maybe that's because tools don't support them, and the vendors aren't complaining enough, or maybe it's just a non-problem and no one cares about them. - Arpad: It sounds like we are leaning toward a Reserved parameter that has Format Table and lists the vendor specific parameters. - Should I start drafting a BIRD along those lines? - Bob: I would like more discussion. - I favor a simple Boolean parameter that says whether it's interoperable. - The description parameter can then be used to list the details: what parameters, how to use them, what tools support, etc. (assuming the Boolean is false - i.e. not interoperable). - Walter: I totally support Bob's suggestion. - John: Use of the table would be to tell the EDA tool which of the Model Specific parameters are not interoperable. - The tools probably already can display description strings so it may be a wash. - Marginal gains and marginal extra work by adding a table. - Todd: I think we've agreed that we have a problem we need to solve. - Arpad: I will start drafting a BIRD. - Thank you all for joining. AR: Mike L. to finalize and post Todd's minutes from last week. AR: Arpad to begin drafting a new BIRD for item #6. ------------- Next meeting: 15 September 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives